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(54) Abstract Title 

Methods and arrangements in a telecommunication network 

(57) The present Invention relates generally to the field of distribution of services In communication networks 
and particularly to provisioning of services In a communication network with a plurality of service systems, 
service providers and service enablers. The system according to the invention provides a system component 
register (SCR) comprising service information relating to a plural'ity of services in the service network (200), 
said service information in stored in service data records, one for each service or group of services. Each 
service data records comprise at least one sen/ice instance field (540) identifying a service mstance for the 
specific service or group of servtees; and, if the specific service or group of services is a complex service or 
utilizes a shared resource, at least one dependency field {BBO) defining dependencies for the specific service or 
group of services to at least one other service system in the service network. 
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Methods and Arrangements in a telecommunication network 

Field of the Invention 

5 The present mvention relates generally to Ihe field of distribution of services in 

cx>nmiunication networks and particidaxly to provisioiung of ^rvices in a conimunication 
network with a plurality of service systems, service providers and service enablers. 

Background of the invCTition 

1 0 Traditionally coxmnunication networks such as mobile telephony networks (PLMN), fixed 
drcuit-switdied networks (PSTN) and data commuxucation netvroxks have been separate 
systems. The telecommunicatian networics have bem diaracterized as vertically integrated, 
meaning that applicadons and services are closely tied to the technique of transport The 
mobile system GSM for example^ provides a set of services and applications, those 

IS ^>pearance, advantages and limitations, at least to a large extent, is given by the 

conmiunication technique. A fixed telephone network (PSTN) has provided a differmt set of 
services and i^lications, closely linked to the conmiunication technique used in the system, 
and the services often differ in usage and s^ypearance fix>m a similar service in a PLMN. 
S^vices that ^ppears similar to the end-user, naay, due to the same close ties to the technique, 

20 be implemented very differently in the different networks. 

The close link between the services and the communication technique has in addition been an 
important reason for the fact that the network operator has also been the dominating provider 
of services to the end-user. To provide a service, knowledge o^ and access to, the complete 
network, has been crucial. A vertically integrated network is depicted in FIG. 1. 

25 Ihore is an increasing demand for a larger variation of services, complex services and to 
allow competition among service provider. At the same time has the tele- and data 
communication networks evolved. The new generations of communication systems integrates 
different communication technologies such as cellular telephony and IP-based data 
coxmnunication. The new systems are often pictured as horizontally layered, with e.g. an 

30 access layer, a core layer and a service layer. In FIG. 2 a layered communication system is 
depicted. In tiiis scenario existing and new players for example operators, service providers, 
service enablers, content providers and application (Internet) service providers interact to 



offer the end-user a large variety of services. The service are offered and managed in the 
service layer, vAdch has the fcmn of a netwoik, the service netwoik 200. The service networic 
200 interacts wt& the core network 210, ^ch typically has a IP architecture and provides 
transport and switching functionality. From the core netwoik it is possible to communicate 
with a plurality of access netwoilcs. The access networks may be of various kinds, including 
cellular systems 220 with different edacity and characteristics such as GSM or UMTS, fixed 
telephony (PSTN) 230, IP based data communication 240, and cable TV 250. The service 
network 200 preferably has an open andiitecture, for «can4)le Op&i Service Architecture, 
OS A and an open inter&ce, for example OSA qyplication program interfoce» API, as to enable 
the multitude of players to interact for providing services to the end-users. A conq^azison 
between vertically integrated networks and layered networks may be found in Ericsson 
Review No. 2, 2001 pages 62-67. 

The offered services may preferably by tailored after the end-user's personal preference, the 
access method (mobile system, fixed system etc)» characteristics of the accessing terminal 
(e.g. the capacity of a mobile terminal), subscription type etc. Although e.g. the access 
method will affect the execution of the service in the service network, many parts of the 
execution of a service will be similar or identical regardless of e.g. the access method. Hence, 
a service provider may use the same building blocks'' to construct different services adqyted 
for different end-users. A building block may e.g. be a directory service, a message service or 
a positioning tool, which also are lefened to as service enablers. The openness of the service 
networks as well as the possibility to use building blocks for more than one particular service 
are ])erceived as key fiictors in attiactiiig both players like operators, service providers and 
service enablers and end-users to develop and use, respectively, new services. 

The offered service will range fiom basic telephony services such as establishing a call 
between two mobile subscribers, to comply services involving different access networks, one 
or more Internet 2^1ications and security services. Complex services may include service 
using positioning, messaging and e-commerce. A positioning based service could e.g. be 
finding a hotel near tibie position of the end-user. Such a service could involve using the 
positioning tools of the mobile system via the mobile positioning centre, one or more Internet 
applications for finding and categorizing hotels in a certain area, i^Ucations ^t transforms 
the information to a format suitable for presentation on tiie terminal of the end-user, e.g. 
WAP, and e-commerce applications &cilitating secure booking and payment of a room. 
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Another example of complex services relates to what is known as fleet management. 
Information on position of each individual user in a selected group of users is presented to 
one, or all, of the users in the groiq). The position of each user is provided by the positioning 
S3rstem. A user may this way get updated information on the positions of all others in the 
5 group.-llns^type of services may be useful f^^^ 

vehicles. To offer and to execute such services a large number of interfece between dififerent 
service systems are required, and as different service systems may be provided by different 
service enablers, the need for service network and a service network that has an open 
architecture and standardized interfiaces should be obvious. 

10 The multitude of services provided in a service network by a multitude of service providers, 
enablers etc., ttie end-users spread in different access netwcffks and with the demand of 
personalized services and different fomis of payment, will increase Hie demand of correct 
end-user related and service related data and immediate access to this data is crucial. In the 
today exisdng networks data related to the end-users are scattered throughout the network, 

15 and in many cases redundant end-user data is stored and used. Similarly data relating to 

services are spread primarily in the different service systenL The scattered storing of the data 
and the redundancy makes it diflBcult to retrieve and update the information. It will, in the 
existing networics with their scattered data, particularly be difficult to implement and to 
ensure a stable functionality of conq)lex services. One drawback with the scattered data may 

20 be illustrated with the exampte of aend-user ending its subscription to one complex service, 
which for exanq>le relies on apositioning service. All data relating to that subscriber is then 
removed fixmi the service system that provides the positioning service. The end user may still 
want to use otiier complex services tiiat uses the positioning, but since the end-user related 
data has been removed fiom the service system that provides the positioning service, these 

25 other complex service will lack crucial md-user related data. The complex services may in 
some case not be possible to perform, and in other casc^, if the end-user data still can be 
retrieved from somewhere in the network, the execution of the complex service will be 
delayed and/or result in increased traf&c load. 

Not only tiie user and subscriber data have the risk of being scattered in the service network, 
30 but also information on the available services themselves may easily degenerate in a large 

service network. This service data includes tiie information needed for service jsrovisioning as 
well as executing a service. A typical service network might contain thousand of services and 
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new services, or combination of services, will constantly emerge as well as less successful 
services will dis^pear. In the scCTaiio with service data scattered in the service netvt^it it 
will be difficult for eg. an operator to keep track of all service information needed in oider to 
perform the services an end-user subscribes to, and to offer the end-user new services. 
5 Further, it will be of crucial iniportance to provide new services £ast and accurate, since the 
"lifetime" of certain service wiD be short. 

In the case of conq>lex SCTvices with for exanq>le different service mablers providing the 
different ^%uilding blocks'* of a complex service the present scenario with scattered service 
data will make it difficult and slow, or even impossible, for the jnovider of the conq>lex 
1 0 service to be updated on changes in tte ^'building blocks**, changes that mig^it adversely effect 
the performance of the complex service. 

The problems with existing handling of services in the service network may be summarized as 
follows: 

a) Service are deployed through different service systems in the service network and the 
1 5 relations between the service systems the services are not easily retrieved; 

b) New services should be offered quickly to the end-users; and 

c) Dependencies between the different service systems used by a coinplex service are not 
readily available. 

20 Summary of the invention 

The objective problem is, in a service network for providing coiiq>iex service and/or a 
multitude of services, to provide a m^iod, data model and system for provisioning of 
services. 

The problem is solved by the system as defined in claim 1, the data model according to claim 
25 9and the method as defined in claim 17. 

The system according to one embodiment of the invention provides a system component 
register (SCR) comprising service irKformation relating to a plurality of services in the service 
network, and service data records storing said service information, one for each service or 
group of services. Each service data records comprise at least one service instance field 
30 identifying a service instance for the specific service or group of services; and, if Hie specific 
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service or group of services is a complex swvice or utilizes a shared resource, at least one 
dependency field defining dependencies for the specific service or group of services to at least 
one other service system in the service network. 

The data model according to one embodiment of the invention is adapted to be u«d for 
5 provisioning services in a service network with a plurality of service systems for providing a 
plurality of services. The service data model comprises service information relating to a 
plurality of services in the service network^ said service information is structured in SCTvice 
data objects, one for each service or group of services, and each service data object comprise: 
at least one service instance object identifying a service instance for the ^ecific service or 
10 group of services; and at least one dependency object defining dependencies for the specific 
service or gioiq) of services to at least one other service system in the service network, if the 
spedfic service or group of services is a complex service or utilizes a shared resource. 

The method according to the invention for provisioning services in a service network, wherein 
service information relating to a plurality of services are stored in a system component 
15 register (SCR), comprises the steps of: 

- deploying the service in the service network by providing a first refnesentation of the service 

intheSCR4 

- providing the service by providing a second representation of the service in the SCR, the 
second representation of the service being a specialization of the first representatioxL The 

20 method may fiirtiier comprise the step of: 

- offering the service to end-users, by providing a third representation of the service in a 
common subscriber/user database (CSD), the third representation of the service being an 
specialization of the second represCTtation of the service. 

Thanks to the service comiK>nent register according to the invention and the service data 
25 records, structuied according to the service data model of the invention a centralized 

ITOvisioning of services in the service network is facilitated. By these arrangements a stable 
environmCTt is created in the service network and a fest and secure provisioning of services is 
ensured. 

Definitions 

30 Service Network (SNV corresponds to the service layer in the horizontally layered view of a 
communication system. Nodes, and a plurality of service systems, necessary to provide end- 



user services are consideied as parts of tiie service network. Exactly ivliich nodes iwfaich are 
considered to beloi^ to the service network wUl depend on the implementation. 

Service system - System for providing a service, or part of a service. The service system 
typicaUy belongs to the service network* A service system may use (communicate vnlh) other 
service systems to ^OTOvide a specific service to a end-user^^md axoniplex service may need to 
use a plurality of service system to execute die service. A service system may provide one or 
more different services or parts of services. 

Service instmr-t^ a service system may provide one or more *%uilding blocks^ far providing a 
service, such ^building blocks^ rrfened to as service instances. The service may need only 
one ^building block'' or a plurality of ^^yuilding blocks^ possibly provided by different 
service systems. 

Complex-service- a service that need to engage two or more service systems to provide a 
specific service to the end-user. 

Brief descrqitioii of the figures 

The features and advantages oflfae present invention outlined above are describe 

below in the detailed descrqition in conjunction with die dmwings vidiae like reference 

numerals refer to like elements Ifarou^iout, in vrfiich: 

Fig. 1 is a schematic dmwing of a traditional, vertical int^rated network.; 

Fig. 2 is a schematic drawing of a horizontally layered network comprising a service 

network.; 

Fig. 3 illustrates the relations between basics entities of the present invention; 

Fig. 4 schematically illustrates a service life-cycle; 

Fig. 5 is a schematic drawing of the SCR according to the invention; 

Fig. 6 is a schematic drawing of the SCR according to one embodiment of die invention; 

Fig. 7 is a schematic drawing of a provisioning tenqplate according to one CTibodiment of the 

invention; 

Fig. 8 is a schematic drawing of an example of service information stored in the SCR 

according to one embodiment of die invention; and 

Fig. 9 is a schematic drawing of die UDM according to the invention. 
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Detailed description of liie invention 

Embodiments of the invention wiU now be described with reference to the figures. 
The control of the vast amount of various information needed for providing and executing a 
services in the service networks is crucial for the provisioning and the p«afomiance of the 
services;as described in the backgroundnsection; Thepresen^invention addresses above 
identified problems relating to the spreading of information m the service network, by 
providing a System Component Register (SCR) typically realised as a common database, for 
the information needed for service provisioning in a service network. The SCR comprises 
information on the type of services, description of the services, specification of the service 
system or systems in vrfiich a service is instaUed and a service dependencies on other services . 
Hraice, the information needed for preferably aU service provisioning in a service networic can 

be accessed via the same entity in the network. 

The service data stored in the SCR is structured according to a Service data model (SDM). It 
should be understood that the SCR provides information about the service as such and does 

15 not hold any information on subscribers or users. This Subscriber/user data is preferably 
stored in a Common Subscriber/user Database (CSD) which is separated fiom the SCR. It 
should also be understood that the SCR provides fee information needed for the provisioning 
of a service- the actual execution of a service is handled by the service system itself; possibly 
with information retrieved &om the CSD. 

20 The above mentioned CSD holds common user and subscriber data that is used by a pluraUty 
of services in the service networic. as well as the relationship between subscriber and users 
and links to affiliate data. The affiliate data is typically aid-user related data that is specific 
for a service, or a group of services, and only relevant for a specific service system. The 
common user/subscriber data is stored in accordance with a User Data Model (UDM). 

25 The management of data, both user/subscriber data and service data is particularly critical in 
the provisioning of complex services. Complex service often require involvement of two or 
more systems for providing services, as for example m the previously described exanq>le of 
booking a hotel. A positioning based service would typicaUy involve the systems mobile 
positioning centre, MPC and the home subscriber server, HSS, where the user's profile for the 

30 mobile network (access network) is stored. The systems like MPC and HSS are example of 
the previously mentioned "building blocks", or service enablets necessary to bmld a complex 
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service. Another example of a shared resource utilized by a plurality of conqilex services is a 
calendar. A user typically wants only one calendar showing all entries regardless of how the 
different entries have been created. In tiie above example of booking a hotel, the service 
booking a hotel preferably also flccess Ihe calendar to smtrnntsMns^Uy mntt^ tlw jwai^tyation The 
user uses the same calendar to book meetiogs, remember birthdays etc.In a business scenario 
a subscriber may want all its users to have access to a common calendar, or each others 
calendars, to be able to use functions that for example automatically checks when a groxq> of 
users are free to have a meeting. Hmce, the service ^calendar^' can depending on the use, be 
regarded as a stand-alone service, or a building block^» or service enabler, for conqilex 
services. In order to prevent that data necessary for one service sjrstem is changed or removed 
by another, for example that one advice system which uses the MPC terminates the 
subscription/activation of the MPC if anoflier service system needs the subscription/activation 
to perfoim its complex service, liie dqvendendes between the service systems have to be 
specified. 

The relations between services, service S3fstems and service instances is further illustrated by 
the following exan^le. The two sovioes Local Movie Sovice and News Update Service are 
offered, uses service system A and B, News Update Service uses service system B a^ 
Hence the Local Movie Service has two service instances, one in service system A and one in 
service system B. News Update also needs two service instances, one in service sj^stem B and 
one in service system C. 

Three basic endties are important in understanding how services are dqiloycd, provided and 
offered in the s»vice netwofk. The three entities, the subsoiber, the user and the service, and 
theu- relations are illustrated in FIG. 3. The entity subscriber 310 suhscnbes to one or more 
sets or packages of services 325 provided in tiie service network. The subscriber 310 owns 
one or more users 305. The user 305 are tiie one actively taking advaitfage of a service 320. 
The user can only use services belongmg to the set of service 325 the subscriber 310 
subscribes to. The user 305 will always have to belong to a subscriber 310. The subscriber 
310 will always own one or more users 305. In many cases the subscriber 310 and the user 
305 will be the same person, but for e.g. a business subscriber the subscriber may be the 
company and the users will be the employees of the company. 



The service data is Stored according to a Semce Data Model SDM,^re^^ 

Data Record, SDR, stored in &e SCR. In order to understand the inventive concept of 
providing an SOI it is useful to describe the life-cycle of a service in the sendee ^ 

ftom conception of a new service to flie service being offisred to an end-user. The services are 
entered tp^SCRandfvolved wilbinihe SCR with the aid of provisioning temples, the 
provisioning templates define the information needed by a service system, i.e. tbe template 
provides information on the affiliate data to be provisioned for that service, as well as the 
provisioning operations that are siqjported by the system hosting the service. 

Hence, the provisioning templates not only provides information on what data should be 
provisioned, but also how it should be provisioned. A new service can be pictured as evolving 
in the foUowing steps, described with reference to FIG. 4, wherein the steps describes a 
method of provisioning a service in a service network according to the invention: 

-Deployed service (410). Then a new service has been developed it is mtroduced in the 
service netvwMk as a deployed service. The dq>loyed service is a first representation of a 
service and typically a plurality of diffiaent configurations of the service are possible.. The 
deployed service has been instaUed and registered in the service network. Each deployed 
service preferably have an associated provisioning template, the deployed service 
provisioning template 440. The main purpose of this template is to describe the user data that 
needs provisioning, and to define the operations that are supported by the service system. 
-Provided service 420. The provided service define diflEerent configurations of the deployed 
service. Each configuration represents a provided service and are a second representation of a 
service. The deployed service might for example allow 100MB of storage per user for an 
email service, but the opaator might want to Imiitthis to 10MB per user. This illustrates how 
the service should be viewed ftom Ae perspective of customer relationship management 
system or business management systems. A provided service provisionmg tanplate 450 is 
associated with the provided service. Since the provided service is a specialization of the 
deployed service, the provided service provisioning template 450 will be based on the 
deployed service provisioning template 440. It is however possible to make fiirther 
specializations of the information m the deployed service template in the corresponding 
provided service template. A fiirther purpose of the provided service is to do the naapping of 



10 

affiliat e commands and attributes to the interface that will be provided towards the business 
system. 

-Offered service 430. A provided service is presented to the user or subscriber as an offered 
service. The offered service represents a third representation of a service and will typically be 
amodification of the provided service 420 to suit a specific customer segment. Hds 
specialization vnU be specified by the offered service provisioning template 460. 

The provisioning template for deployed 440 and provided services 450 resides in SCR, while 
the provisioning template for offered service 460 resides in CDS. The provisioning tenq>lates 
440, 4S0» 460 may preferably be stored as XNfL files. 

The entities in the SCR should reflect the service life cycle and define links to service 
instances. The implementation may vary depending on the technology used to build the CSR, 
but fhc logical grouping should be the same. The following main entities, schematically 
deleted in FIG. 5» shoidd be comprised in the CSR: 

- Deployed service 510: contains information on a service that has been installed and 
registered in the service network. The entity deployed service describes ail capabilities of 
a service and specifies all data, in particular user and subscribe data, needed to provision 
the service; 

- Provided service 520 is a specialization of the deployed service 510. The specialization is 
e.g. a limit a ti on of allowed memory size for each user in an e-mail application. The 
spedalization, e.g. limitation, is set for example by a system operator 

- Service system 540, comprises information specifying the service instance and addressing 
means to the service instance. If viewed fix>m an afBliate data perspective, the service 
system 540 specifies an affiliate instance and addressing means for &e affiliate instance. 

Service dependencies 550: Depradencies between services building up a complex service 
or using a shared resowce is stored in the SCR in the entity service dependencies 550 . 

Templates 560: The service data will be entered to the SCR with the aid of templates. 
Also the specialization of a service represented by the provided service and tiie deployed 
service will be performed according to templates. The templates will preferably be stored 
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in an fonnat that is compact and easUy exchangeable, for example as XML files 
(extended Mariaip Language).The provisioning templates for deployed 561 and provided 
services 562 resides in SCR, while the provisioning template for ofBsred service 563 
resides in CDS 

5 - Offered service 530, is a specialization ofa provided service 520, reflecting an adaptation 
to a customer segment and or a service package. A provided service 520 may result in a 
pluiaUty of offered services 530. The offered service 530 represent Ae connection 
between the data in the UDR and the SCR- Stricfly, the offered service is not an entity 
within the SCR, it belongs to the UDM, but is inchided here to further illustrate the 

1 0 lelatioiiships to entities within tiie SCR (provided service 530). 

The storage of service data, including the provisioning templates, in the SCR should be m 
accordance to the Service Data Model, ^ch will be described with references to FIG. 6. 

The SDM comprises the below described objects. A realisation of the SCR will comprise 
service data records according to the SDM, wiiich service data record wiU have for example 
15 fields corresponding to the below described objects. Examples of service data records for 
some exemplifying services are provided below. The SDM comprises the ol^ects: 

- Service Group 605: The ServiceGroiqj object is a placeholder for services. Services firom 
one service provider can for instance be put together under one service group while the 
services that belong to another service provider can be put under another service group. The 

20 management ofthe service groiq> is preferably performed by a Service Administrator. 

- Service 610: The Service object is the placeholder for all information regarding one service. 
The service status attributes is mandatory and holds the status of the service. 

- Service Access Definition 615: For each service one Service Access Definition object can be 
created. The Service Access Etefinition object holds mformation about how the service is to 

25 be used. 

Provisioning Access Definition 620: For each service one Provisioning Access Definition 
object can be created. The Provisioning Access Definition object holds mformation about how 
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the service is to be provisioned. This object specify the provisioning template for the 
deployed service. 

- Service Instance 630: One service is installed on one or more service instances. The Service 
Instance object holds information about cme service instance. Attributes of this object should 

S specifies the service access point for the service instance and if the service requires 
provisioning specify the provisioning access point for the service instance. 

- Provided Service 640: When a deployed service is evolved to a provided service one 
provided service object is seated for the service. An attribute should specify the provisioning 
tenq>late for tibie provided service. This provisioning tenq)late is refined from the deployed 

1 0 service provisioning template. 

- Service Dependoicies 6S0: If the service is dependent on other services the service 
depradencies object is created. A mandatory muhi-value attribute should specify the service 
identities for all dependent provided services. 

Referring to FIG. 6, the Service Instance 630, and Service 610 and has a correspondence in 
15 the main endty Service System 540. 

The Provisioning Access Definition 620 is created ivfaen ftxc deployed service is created. 
When the provided service is created the "Provided Savice" object 640 is added to the 
information in the SCR. Hence» the SCR data for a provided service will contain hoih the 
provided service provisioning template and the deployed service provisioning template. This 
20 is necessary if one later wants to remove the provided service but keep the deployed SCTvice 
information. 

The provisioning templates are crucial for the provisioning of the correct information in each 
of the steps of the evolution of a service. The ten^lates are within the SDM and the contents 
of the templates depends on if it is a t^nplate describing a deployed service, a provided 
25 service or an offered service. However, a general structure will be the same for all 
provisioning templates and will be described with references to FIG. 7. 

As indicated in the figinre a provisioning traiplate 700 will comprise the following main parts: 

- Template heading 705, conqirising a standardized XML schema header. 
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- Provisioning protocol information 710, describing the affiliate data that needs provisioning 
and the inrovisioning requests siq)ported; 

- Mapping rules720 describing how the provisioning requests siq>ported in s^lication 
(affiliate) system should be mapped towards a business management systems. Mapping rules 

S does not exist for deployed services; and 

- Service Policy 730 describing whm and how the service can be used. 

The provisioning protocol information 710 may further comprise some of the following parts, 
which should be considered as example of information provided in the provisioning protocol 
information 710. 

10 - Provisioning Protocol 71 1, deciding the provisioning inter&ce siqyported by tiie afBliate; 

- Command Template 712, conqirising information about the affiliate commands possible to 
send towards the affiliate. The contents in this section differ depending on the provisioning 
inter&ce supported by the affiliate, 

- Attribute List 713, describing all the attribute required for provisioning of the service in the 
15 affiliate The attribute list will always contain the attribute name, data Qrpe and de£ault values. 

The allowed datatypes of the attributes deprads ontfae interfieuse that will be used towards tiie 
affiliate. 

- Shared Resource Attributes 714, defining attributes that relates to shared resources. The 
shared resource attribute 714 always refer to an existing attribute in the Attribute List 713 . 

20 - Context Attributes 71 5, is the key identifier for a user or a subscriber in the affiliate system. 
The context attribute 715 always refer to an existing attribute in the Attribute List 713. 

How data is stored in the SCR according to tiie preset invention will be fiirther illustrated in 
an example described with reference to FIG. 8 a and b. The Data is stored in accordance with 
the Service Data Model, SDM, which is described with reference to FIG. 6 and FIG. 7 which 
25 also are referenced in this example. In the illustrative example the four service are stored and 
have corresponding data records: Local Movie Advertisement 810:1, Local Weather Forecast 
810:2, Mobile positioning 810:3 and Bank service 810:4. Each service data record comprises 
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several attributes including a service ID, a service name and a service status. Tlie service are 
grouped into two service groups, service group A 805:1 and service group B 805:2, 
resp)ectively , according to supplier. Other means of groiq)ing are possible. Each record 
service group comprises a service group ID and a service group name. Local Movie 
5 Advertisement 810:1 and Local Weather Forecast 810:2 belongs to service grovp A 805:1. 
Mobile positioning 810:3 and Bank service 810:4 belongs to service group B 805:2. 

Each service will have more detailed service information stored, as illustrated in FIG. 8b. This 
information will comprise specifications on the service dependencies 850: In the example 
Local Movie Advertising 810:1 is dependent on Mobile positioning 810:3. This dependency 
10 is defined in the field Service dependencies 850 preferably by specifying the service ID of the 
Krvice (Mobile positioning) to ^^ch local Movie Advertising is dq>endent 

Local Weather Forecast is dependmt on Mobile ]>ositioning 830 and Bank service 840 (not 
shown). In this case the Service dependencies 865 will include two service ID'^s referring to 
Mobile positioning 830 and Bank service 840» respectively. 

15 The service information provided by the service data record further comprises, in accordance 
widi SDM (FIG.6) the fields Provisioning Access Definition 820, Service Instance 830, 
Provided Service 940 and Service Access Definition. The purpose of those fields is specified 
above in the description of the SDM. 

The separation of user/subscribar information (stored in CSD), service infonnation (stored in 
20 SCR) and affiliate data is an important part of the invrative concept of the present invention. 
To illustrated the relationships between the CSD and ite SCR a desoiption of the CSD and 
tiie User data model will be given. 

The user/subscriber data is stored according to a User Data Model, UDM, resulting in aUser 
Data Record, UDR, stored in the CSD. timt comprises actual user-related data and end-user 
25 subscr^ons to services. The principle of the user data model will be described with 

references to FIG. 9. The user data record, UDR will be constructed after the jmnciples of the 
UDM. The structure of the data stored in the CSD has to be carefully designed, to avoid 
internal replication of data, provide the correct links to the systems for providing services and 
maintaining the needed data in the most logical way. The data is logically grouped into 
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objects, with key objects beic^ subscriber, user and service, in correspondence to the main 
entities described above. An ol^ect corresponds to a field in the UDR. The arrows in the 
figure indicates links between the objects. Hie implementation may vary depending on the 
technology used to build the CSD, but the logical grouping should be the same. 

5 The following objects should preferably be comprised in the UDM: 

* User 90S: contains basic User informatidn (e.g. user identities). A user 905 is always 
belonging to a subscriber 910; 

- Subscriber 910: contains basic Subscriber information (e.g. subscriber identities); 

- Customer Segment 915: used to classify subscribers 910. Contains customer segment 
10 description and basic data; 

- Offered Service 920: contains service basic information; 

- Service Package 925: used to package services 920; 

- Service Package Subscription 930: used to reflect an effective subscription to a service 
package 925 by a subscriber 910; 

1 5 - Service Subsaiption 935: used to reflect effective subsCTiptions to individual services 920 
in a service package by a subscriber, specified by the service patkajge subscription 930; 

- Sendee Activation 940: used to reflect effective activation to an individi^ 
the service subsoiption 935 by an user 905; 

- If dependencies between service systems are to be handled within the UDR the Subscriber 
20 Shared Resoiuice 945 contains basic data of the shared resource being used in a certain 

service subscribed by a subsraiber 910 and specified by the service subscription 935; and 

- User Shared Resource 950: contains basic data of the shared resource being used in a 
certain service activated 940 by an user 905. 

The user object 905 and the subscriber object 910 are examples of identification objects. The 
25 service subscription object 935 and the service activation objects 940 are examples of service 
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objects. All services present in the service network 200 is known by the UDM. The subscriber 
910 may then subscribe to a service. The object offered service 920 contains information on 
all the offered services and hold references or links to service data stored in the SCR 970» 
represented by the object provided service 975 (640). This is preferably the only direct link 
5 betweoi the UDR data and the SCR. A subscriber 910 could subscribe to sendees one by one, 
but this would make the provisioning cumbersome. Preferably similar services, or service 
likely to attract the same subscriber, are grouped together vMch is reflected in iho object 
sendee package 92S. A certain service may be offered in a plurality of service packages. 
Additionally, a service package may be offered to a groiq> of subscribers with Ae same 
10 characteristics and esq^ected needs. Hmce, subscribers 910 may be grouped into customer 
segmmt 915, and the subsoriber 910 may subscribe to all services ofifered to the customer 
segment it belongs to . A service is added to a custcmier segment by iiKsluding it in one or 
more service packages 925. In short, service packages 925 groiq)S services 920 and customer 
seg;meDt 915 groups subscribers 910. 

15 Refening to the example of offered service described reference to FIO. 9, Local Movie 
Advertisemoit 910:1, Local Wea&er Forecast 910:2, Mobile positioning 910:3 and Bank 
service 910:4 are registered in the CSD throng the offered service 920. The services may in 
addition be registered as a service package, specified in service package 925, for example a 
packaged called ''localised service** and including the services Local Movie AdvertisemeDt 

20 and Local Weather Forecast. 

The service component register and the service data records fiunlitate a centralized 
provisioning of services in the service network. Througih the UDM the services are offered to 
the end-users in a imified -way. By these axrangemeat a stable envinrnment is created in the 
service network and a &5t and secure provisioning of services is assured. 

25 While the invention has been described in connection with what is presently considered to be 
the most practical and preferred embodiments, it is to be understood that the invration is not 
to be limited to tiie disclosed embodiments, but on tlie contrary, is intended to cover various 
modifications and equivalent arrangemCTts included within the spirit and scope of the 
appended claims. 

30 Example of a use case 
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Pre-conditions: 

A detailed example of a typical provisioning scenario is given, in vdiich an end-user activates 
the local weather forecast service. The example is based on the following prerequisites: 

-The offered services and services has been set up as described above. 

-A subscriber has been seated. 

-Users belonging to the subscriber has been created. 

-The subscriber belongs to a customer segmCTt that is allowed to provision the **Localised 
services** service package. 

-The subscriber belonging to our end-user has subscribed the "localised services" service 
package. 

Flow of event: 

Below is a description of the typical flow of events when an end-usCT subscribes to the 
service. The exact behaviour will depend on the customer specific set up of the service 
network. 

1 . The end-user wants to browse for new services available on his portal, and uses 
a WAP (Wireless AppUcation Protocol) temiinal to access the portal home page. 

2. Theportal will request the available services for this user by sending a CAI3G 
request to CPE. 

3 . CPE will check what services that are available for this user by checking the 
contents of the service packages subscribed by the subscriber the user belongs to. 
This information resides in the CSD. 

4. CPE responds with a CAI3G response to the Portal. 

5. The Portal creates a WAP page with information about tiie available services. 
Note, the response from CPE only contains the information to present to the end- 
user. It does not contain any infomiation about how it should be pres^ted. The 
Portal should solve this itself by using technologies like style sheets and a terminal 
databases. 

6. The end-user finds the local weather forecast service and the local movie 
advertising service. He decides to activate the local weather forecast service. 

7. The Portal requests the service parameters for this service fix>m CPE. . 
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8. CPE will look in SCR to find any service dependencies. The local weather 
forecast service depends on the positioning service and a bank service. 

9. CPE checks if the end-user already has subsoibed the positioning service and 
the bank service. Since a bank service subscription already existed in CSD, this 
subscription will be re-used, but a ix>sitioning service will have to be created. 

10. CPE reads Ihe offered service provisioning template for the local weather 
forecast service and the positioning service. This information is stored as XML files 
in CD. The XML files will follow the format decided by the offered service XML 
schCPEs. 

1 1 . CPE will concatenate the attribute information fmm the two templates in a new 
XML string, and return this to the Portal. 

12. The Portal will create anew WAP page with an input field for every attribute it 
finds in&e XML response fiom CPE. It will put a label corresponding to the 
attribute name» and an iiqKit field that suits the data type of the attribute. 

13. Theend-user will fill in all the input fields in the GUI and click the OK button. 

14. The Portal will validate the data according to the attribute information that was 
provided by CPE. It will check that all mandatory attributes has been filled in, and 
that all data is within Ihe specified valid ranges. 

15. The Portal sends a CADG request to create the subscription towards CPE. As an 
input parameter it will include the XML string with all fiUed-in end-user data. 

16. CPE will get service instance data from SCR and select the most appropriate 
instance to provision the user to. This will be done based on the result of the 
distribution alpmOam (also found in the SCR). 

17. CPE creates the afiSliate provisioning commands according to the deployed 
service provisioning template found in the SCR. 

18. CPE sends the provisioning commands towards affiliates (using CAI3G» CAI or 
LDAP) 

19. CPE iqxlates the user's data in CD. 

20. CPE updates E-AAA. 

21. CPE sends an OK response to the Portal 

22. CPE notifies CAS (Customer Admmistrative System) (if the CAS has 
subscribed to notifications on this type of events) 
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Claims 

1. A system adapted for provisioning services in a s^vice network (200) with a plurality of 
service systems for jiroviding a plurality of services, wherein the system comprises a 
system component register (SCR) conq^rising service information relating to a plurality of 
services in the service netwodc, said service information is stored in service data records, 
one for each service or group of services, and i^dierein each service data records conqprise: 

- at least one service instance field (540; 630) identifying a service instance for the 
specific service or groiq> of services; and 

- at least one dq>endCTcy field (550; 650) defining dependencies for the specific service or 
group of services to at least one other service system in the service network, if tiie specific 
service or group of services is a complex service or utilizes a shared resource, 

i^ereby the service component register and the service data records facilitate a 
centralized provisioning of services in the service network. 

2. Syston according to claiml, wherein the service data record further comprises: 

- a service field (610), which holds information regarding one service; 

- a service access definition field (615), which holds information about how the service is 
to be used; 

- a provisioning access definition field (620), w^ch holds information about how the 
service is to be provisioned. 

3 . System according to claim 2, \s4ierein the service data record further comprises the fields: 

- deployed service field (510), vdiich comprises information on a service that has been 
installed and registered in the service network.; and 

- provided service field (520; 640), which represent a specialization of the deployed 
service. 

4. System according to claim 2, wherein the service data record further comprises at least 
one template field (562, 561 ; 620, 640) specifying provisioning templates relevant for the 
service, said provisioning templates defining the information needed to provision a service 
and the provisioning operations supported by the service syst^n. 
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5 . System according to claim 4, wherein at least one of the provisioning templates are stored 
in the SCR. 

6. Sjrstem according to claim 4, wherein the provisioning templates are stored in an format 
that is compact and easily exchangeable, for example as XML files (extended Maikiq) 
Language). 

7. S3^stem according to claim 2, wherein the provisioning access definition field (620) further 
specify the provisioning ten:q>late for a deployed service. 

8. System according to claim 1, wherein the service data record further comprises a service 
gfoup (60S) field identifying at least two sendee that are grouped together. 

9. A service data model ^6^p^^ to be used for provisioning services in a service network 
(200) with a plurality of service systems for providing a plurality of services, wherein the 
service data model comprises service inf ormadon relating to a plurality of services in the 
service network, said service inf ormadon is structured in service data objects, one for each 
service or group of services, and v^ierein each service data otgect comprise: 

* at least one service instance object (540; 630) identifying a service instance for the 
specific service or groiq> of services; and 

. at least one dependency object (550; 650) defining dependoicies for the specific service 
or groiq> of snvices to at least one other service system in the service network, if die 
specific service or group of services is acomplex service or utilizes a shared resource, 
>7s4iereby the service data model fiunlitate a centralized provisioning of services in the 
service network. 

10. Data model according to claim 9, wherein the service data object further comprises: 

- a service object (610), wliich holds information regardiag one service; 

- a service access defiidtion object (615), which holds information about how the service 
is to be used; 

- a provisioning access definition object (620), which holds information about how the 
service is to be provisioned. 

1 1. Data model according to claim 10, wherein die service data record further comprises the 
objects: 
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- deployed service object (510), which conqnises information on a service that has been 
installed and registered in fhe service network.; and 

- provided service object (520; 640), ^ch represent a specialization of the deployed 
service. 

5 12. Data niodel according to claim 9, v^erein the service data object fm^ 

one template object (562, 561) specifying provisioning templates relevant for the service, 
said provisioning templates defining the information needed to provision a service and flie 
jsrovisioning operations supported by the service system. 

13. Data model according to claim 12, wherein at least one of tlie provisioning templates are 
10 stored in the SCR. 

14. Data model according to claim 12, v^erein tiie provisioning templates are stored in an 
format that is compact and easily exchangeable, for example as XML files (eXtended 
MarkiQ) Language). 

15. Data model to claim 10, wherein the provisioning access definition object (620) fiirther 
1 5 specify the provisioning template for a deployed service. 

16. Data model according to claim 9„ v^erein the service data object further comprises a 
service group object (605) identifying at least two service that are groitped together. 

1 7. A method of provisioning services in a service netwoik, ixdierein service information 
relating to a plurality of services are stored in a system component register (SCR), the 

20 method comprising the steps of: 

- deploying (410) the service in the service network by providing a first representation of 
the service in flie SCR4 

- providing (420) the service by providing a second representation of the service in the 
SCR, the second representation of the service being a £9>ecialization of the first 

25 representation. 

1 8. The method according to claim 1 7 further comprising the step of: 

- offering (430) the service to end-users, by providing a third representation of the service 
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in a common subscriber/user database (CSD), the third representation of the service being 
an specialization of the second represratation of the service. 

19. The method according to claim 17 wherem the step of deploying (410) the service is 
performed by using a deployed service provisioning template (440), i?^ch specify user 
data to be provisioned and to define tiie operations fbat are supported by the service 
system providing the service. 

20. The meOiod according to claim 17 \\Aerein the step ofproviding (420) the service is 
performed by using a provided service provisioning template (450). 

21. The method according to claim 18 vsdiereinthe step of offering (430) fte service is 
performed by using a offered service provisiomng template (460). 
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